The development of typical software applications of even nominal complexity requires the skills of programmers familiar with a middle-level or high-level programming language such as C++. Often, such programmers develop applications based on functional requirements specified by end-users of the applications. While the end-users are typically unfamiliar with programming, they are highly skilled in the activities that employ the software applications. Frequently, after an application is generated by the programmers and released to the end-users, the end-users identify errors in the application or enhancements that would improve the usefulness of the application. In the typical software development cycle, after a period of use of an application, the end-users may submit a listing of these errors and/or enhancements to the programmers, who then create an updated application using a high-level programming language.
It is known that a substantial majority of the life cycle costs associated with many software applications are incurred in post-release support activities such as debugging, enhancing functionality, and adapting the applications to changes in the end-use environment. These support activities are expensive because they require the involvement of highly skilled (and relatively highly compensated) programmers who must perform the often time consuming task of writing/rewriting and testing code in a high-level programming language. Such high life cycle costs are particularly problematic for organizations that require large numbers of software applications because they perform a wide variety of tasks and/or multiple tasks that must be performed under changing operational environments. The iterative development approach described above is especially inefficient for software applications that provide relatively simple functionality, a characteristic of many special purpose applications, because it employs highly skilled programmers using high-level programming languages to modify basic functions.
As indicated above, another problem with the conventional software development approach is the inefficiencies that arise from the knowledge gap between the programmers and the end-users about the needs to be addressed by a particular application. The end-user is the expert on the requirements of the application, but can only provide feedback to the programmers because the end-user is typically not qualified to revise the application to incorporate the desired functionality. Thus, the end-user must educate the programmers on the operational environment for the application and the desired functional modifications. This transfer of knowledge takes time, and invariably some portion of the end-user's feedback is lost in the process. The situation is frequently made worse by the physical separation between the end-users and the programmers.
The present disclosure provides a software architecture that reduces the need for involvement of high-level programmers in the life cycle of certain software applications by enabling development and maintenance of such applications without the use of high-level programming languages. As a result, the methods and systems of the present invention should reduce life cycle costs. Additionally, as the development and maintenance of the applications may be performed by properly trained technicians familiar with the requirements of the applications and the operational environments, but not necessarily familiar with abstract programming, the inefficiencies associated with the knowledge gap between the programmers and the end-users may be reduced. For example, the architecture of the present disclosure permits on-site trained, non-programmer technicians to work with end-users to provide application updates, rather than requiring communication with remote programmers who are less familiar with the actual deployment of the application.
More specifically, the present disclosure provides a software architecture for development of applications having functionality that can be effectively modeled using finite state machine elements. This characteristic is common to many special purpose software applications that enable an end-user to perform a particular task or set of tasks that involve a manageable number of different stages or states. Although the present disclosure refers to the creation and maintenance of applications of relatively low complexity, it should be understood that, in theory, any software application can be modeled using finite state machine elements. The present system generally includes a dynamic state machine processor (DSMP) that manages execution of finite state machine elements representing the functionality of the software application (referred to hereinafter as an “FSM model”), an extensible graphic user interface (GUIX) with functionality that is entirely dependent upon the FSM model, and a visual interface for programming extensible routines (VIPER) that enables technicians without high-level programming experience (but trained on the use of VIPER) to create and modify FSM models using a graphic environment with drag/drop finite state machine elements.
As is further described below, the DSMP provides the execution environment to the end-user by accessing a database of markup language descriptions associated with the various elements of the FSM model and a library of standard actions that are called by the descriptions. Any of a variety of suitable markup languages, or similar languages, may be used. This description will refer to XML as the markup language as an example only, and not to limit the scope of the disclosure. The standard actions are basic software functions typically written in a high-level programming language, such as mathematic functions, that perform discrete actions that are common to many applications. Using both the XML code in the database and the standard actions specified by that code, the DSMP executes the various steps necessary to generate the actual software application run by the end-user.
As part of its execution of the application, the DSMP interacts with the GUIX to provide the features needed to permit the end-user to interface with the application. In one embodiment of the system, the GUIX includes no hard-coded interface features, but instead provides during run-time only those interface features specified by the currently executing FSM model. As indicated above, these interface features are specified by the primary inputs to the DSMP (i.e., the XML descriptions of the FSM elements and the standard actions called by the XML descriptions). Accordingly, the functionality of the application is provided by the DSMP and the GUIX, and is dependent only upon the XML descriptions for the FSM model. As such, the functionality of the application may be modified (or created) by simply modifying the XML descriptions, which is an activity that does not require familiarity with a high-level programming language.
Creation and modification of the XML descriptions is carried out by the technician using the VIPER environment. VIPER permits the technician to retrieve an existing FSM model and view the various FSM elements of the model in a graphic environment. As explained in detail below, the technician may then rearrange, delete, add or otherwise modify the individual FSM elements to achieve the desired modifications to the functionality of the FSM model. The technician may also create entirely new FSM models using VIPER. After a model is created or modified, the technician may save the model, thereby causing VIPER to automatically create the appropriate XML descriptions corresponding to the model and write those descriptions to the database for use by the DSMP.
These and other features of the present disclosure will be readily apparent to those skilled in the art upon reference to the following description and the accompanying drawings.
Although the drawings represent embodiments of various features and components according to the present invention, the drawings are not necessarily to scale and certain features may be exaggerated in order to better illustrate and explain the present disclosure. The exemplifications set out herein illustrate embodiments of the disclosure, and such exemplifications are not to be construed as limiting the scope of the disclosure in any manner.